Copy On Write {pintos}{swjungle}
wiki 정리
https://en.wikipedia.org/wiki/Copy-on-write
PTE ⟶ mark as read-only, keep count of the number of the refs
- only one ref ⟶ skip new allocation
- greater than 1 ⟶ allocate new page, decrementing ref count from original page
Drawing 2023-10-22 06.00.07.excalidraw
cow-simple은 통과하는데...
hidden test case가 존재하지만 정확히 어떤 부분을 컨트롤해야 하는지 모르겠다. 지금 커널모드의 WP(Write Protection) 비트도 꺼져있어 반쪽짜리 COW임이 분명하고 권 교수님 말씀대로 구조를 뜯어고친것도 아닌데 테스트케이스가 통과하는 것이 매우 의심스럽다. 숨겨진 테스트 케이스를 알아내기 위해서 질문방에 글을 올렸으나, 조교진들도 알 수 없다는 답변에 좀 더 구체적인 힌트를 요구하기 위한 질문을 작성하려고 한다.
다음 시나리오들은 저희가 생각해본 cow 메커니즘이 올바르게 작동하는지 여부를 확인하기 위한 테스트들입니다. 추가할만한 채점 고려사항이나 테스트 자체의 의도에 대해서 첨언해주신다면 정말 감사하겠습니다.
- 먼저 swap in/out을 적극적으로 사용하는 시나리오입니다. 부모가 페이지 크기의 지역변수를 선언합니다. 그 뒤로 자식 프로세스를 여러개 선언한 뒤 각 프로세스가 지역변수를 write하게 만들어 COW와 swap이 동시에 의도한 대로 이루어지는지를 테스트합니다.
- 테스트케이스는 유저프로그램의 입장에서 실행되는건데, 유저 프로그램이 특정 페이지가 swap in되었는지 out되었는지 알기는 힘들 것 같습니다. 그것은 커널이 관리하는 영역이지, 유저 프로그램한테 노출하는 정보는 아니기 때문입니다.
- syscall을 통해서 간접적으로 cow를 테스트할 수도 있을 것 같습니다. 저희 코드는 현재 CR0 레지스터의 write protect bit를 꺼놓은 상태로 구현을 했습니다. 이 경우 유저 프로세스가 직접 write 요청을 통한 페이지 복제는 가능하지만
read를 통한 간접적인 버퍼 쓰기요청에는 page fault가 발생하지 않을 것으로 예상됩니다.- 네 syscall을 이용한 테스트케이스는 필요해 보입니다. 말씀해주신 상황에서 커널이 값을 쓰는 경우에도 page fault가 발생하여 copy-on-write를 해야합니다.
- 저희는 현재 프레임의 reference count가 1인 프레임만 추방시키는 eviction policy를 가지고 있습니다. 따라서 모든 프레임들의 reference count가 2 이상인 경우의 케이스를 다룰 수가 없습니다. 하나의 프레임을 공유하는 프로세스 관계가 일대다인 경우를 위해서 구조를 변경할 필요가 있습니다.
- 네 사용중인 eviction policy는 evict가 불가능해지는 상황이 가능해지므로 고치는게 나아 보입니다.